Formal operation definition in object-oriented databases

ion of the result of an expression, it is obvious that without result, a type for an expression is irrelevant. Obviously, there is more to heterogeneity than just the addition or modification of typing rules. It has a profound impact on the meaning of a type, hence on the meaning of expressions. In Section 5.3.6, we have seen that heterogeneity is one of the causes of update anomalies if not properly guarded with additional typing restrictions. Also, heterogeneity may be ‘lost’ if the semantics of expressions are not carefully defined with retaining heterogeneity in mind. For example, the semantics of the except-expression for sorts (see Section 4.6.4) is of the form in D(out D([[E]] T X) except ( )) If the run-time type of E is a subtype of D, then this run-time type is not maintained by the except-expression, because the result always has run-time type D as a result of the explicit in D( ). This ‘loss of heterogeneity problem’ may occur in the semantics of other expressions too. A promising solution would be to enhance FLORENCE with an unitop(e; e )-expression that can perform operation e on unit value e while preserving its the run-time type: T ` e 0 : T ` e : K( )! K( ) T ` unitop(e; e ) : [[unitop(e; e )]]V TgK( val([[e]]V)( val([[e ]]V)); tag([[e ]]V)) This would allow a semantics of except that does not exhibit the loss of heterogeneity problem: unitop( x :hhii : x except ( ); [[E]]TX) Apart from this problem, TAMARA has gained much in convenience of specification compared to TM with the advent of heterogeneity. The example of Section 4.3 illustrates this clearly. The lack of heterogeneity, heterogeneous sets in particular, were an often heard criticism of TM, especially because of the database context. Overloading and overriding As explained in Section 3.9, the full potential of heterogeneity can only be exploited in combination with late-binding. Late-binding is provided in TAMARA in the form of overloading and overriding of domain members. The basis for late-binding provided by FLORENCE in the form of overloaded functions proved successful. From the general idea of mapping identically named domain members to one overloaded function and the typing rules and well-formedness of overloaded functions, the typing rules for domain member overloading and overriding naturally emerged. Furthermore, by incorporating the concept of binary methods, overloading and overriding appeared to be two sides of the same medal. This allowed an approach that covers both. Section 5.2 provides a systematic description of how the typing rules for overloading and overriding are deduced and what the relationship between overloading and overriding is. 5.5. TAMARA in retrospect 183 One aspect of the way overloading and overriding are incorporated into TAMARA deserves some improvement. For example, the method m(p:Tj):To of class D is considered to override m():To of the same class. Hence, To To is required which is a bit awkward, because a different number of parameters usually suggests overloading, hence no requirements are needed for the output types. The reason for this behaviour can be traced to record formalization. The dispatching record type h p0:D; p1:Ti is a subtype of h p0:Di. If the number of parameters should be determinative, a record type is not the best choice here. A formalization based on a tuple type hh 1; : : : ; nii with a subtyping rule